Repository navigation
ref: Make span types more robust - #10660
Conversation
size-limit report 📦
|
|
Oh wow, If this fixes the issue, it's might be worth adding a test of some kind to ensure we don't break |
Yeah, it's a bit obscure and hard to reason about IMHO 😬 Let's see if that fixes it first, maybe we can opt-into this stricter setting in our TS E2E test 🤔 |
With more strict TS settings, these could lead to problems: 1. `startChild()` should return a span interface, to match the interface implementation. 2. no need to overwrite `updateName` for transaction, this messes with the inherited type `this` as the this is now a transaction, not a span... we can skip this. Fixes #10654
70167a8 to
15e3745
Compare
|
OK, I actually tried this on the reproduction, and turns out the |
|
and incompatible. This is more in-line with the actual javascript runtime (e.g.): |
Lms24
left a comment
There was a problem hiding this comment.
Hmm I guess this falls into the "if this is what we have to do then let's do it" category 😅
With more strict TS settings, these could lead to problems: 1. `startChild()` should return a span interface, to match the interface implementation. 2. All properties that are optional in span/transactions need to also accept `| undefined` to be really correct - otherwise when we extend this and set `undefined` explicitly it complains there. Fixes #10654
With more strict TS settings, these could lead to problems:
startChild()should return a span interface, to match the interface implementation.| undefinedto be really correct - otherwise when we extend this and setundefinedexplicitly it complains there.Fixes #10654